The Synchronous Optical Network (SONET) is a group of standards that define a hierarchical set of transmission rates and transmission formats for carrying high-speed, time-domain-multiplexed (TDM) digital signals. SONET lines commonly serve as trunks for carrying traffic between circuits of the plesiochronous digital hierarchy (PDH) used in circuit-switched communication networks. SONET standards of relevance to the present patent application are described, for example, in Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria (Telcordia Technologies, Piscataway, N.J., publication GR-253-CORE, September, 2000), which is incorporated herein by reference. While the SONET standards have been adopted in North America, a parallel set of standards, known as Synchronous Digital Hierarchy (SDH), has been promulgated by the International Telecommunications Union (ITU), and is widely used in Europe. From the point of view of the present invention, these alternative standards are functionally interchangeable.
The lowest-rate link in the SONET hierarchy is the OC-1 level, which is capable of carrying 8000 STS-1 frames per second, at a line rate of 51.340 Mbps. A STS-1 frame contains 810 bytes of data, which are conventionally organized as a block of nine rows by 90 columns. The first three columns hold transport overhead (TOH), while the remaining 87 columns carry the information payload, referred to as the synchronous payload envelope (SPE). The SPE contains one column of payload overhead (POH) information, followed by 86 columns of user data. The POH can begin at any byte position within the SPE capacity of the payload portion of the STS-1 frame. As a result, the SPE typically overlaps from one frame to the next. The TOH of each frame contains three pointer bytes (H1, H2, H3), which are used to indicate where in each frame the POH begins and to compensate for timing variations between the user input lines and the SONET line on which the STS-1 frames are transmitted.
STS-1 frames can efficiently transport the DS-3 level of the PDH, which operates at 44.736 Mbps. The STS-1 frames themselves are not too much larger than DS-3 frames. Each DS-3 frame may carry multiple lower-rate PDH signals, such as DS-1 or E-1 signals. When PDH signals at rates below DS-3 are to be carried over SONET, the SPE of the STS-1 frame is divided into sections, known as virtual tributaries (VTs), each carrying its own sub-rate payload. The component low-rate signals are mapped to respective VTs, so that each STS-1 frame can aggregate sub-rate payloads from multiple low-rate links. Multiple STS-1 frames can be multiplexed (together with STS-Mc frames) into STS-N frames, for transmission on OC-N links at rates that are multiples of the basic 51.840 Mbps STS-1 rate.
For the purpose of VT mapping, each STS-1 frame is divided into seven virtual tributary groups (VTGs), each occupying 12 columns of the SPE. Within each VTG, four VT sizes are possible:                VT1.5—occupies three columns, each with sufficient bandwidth to transport a DS-1 signal at 1.544 Mbps (i.e., the signal carried on a T-1 line). One VTG can contain four VT1.5 sections.        VT2—four columns, bandwidth sufficient for an E-1 line.        VT3—six columns, bandwidth sufficient for DS-1C.        VT6—twelve columns, bandwidth sufficient for DS-2.Mapping of the VTs to the columns of the SPE is specified in detail in the above-mentioned Telcordia publication GR-253-CORE, section 3.2.4. It is not necessary that all of the VTs in a STS-1 frame be used to carry lower-rate signals. Unequipped VT sections, i.e. sections that have no service to carry, in the SPE are simply filled with default (idle) data. In SDH systems, STM-1 frames are similarly divided into sub-rate payload sections of different sizes, referred to as TU-11, TU-12, and TU-2.        
Although SONET and SDH were originally designed for carrying synchronous data, such as voice, legacy TDM networks and trunks are now commonly used for carrying non-synchronous packet data services, as well. Signal types and “containers” (such as the SPE) that were originally designed and optimized for voice services have been adapted for a variety of data transmission services, such as Frame Relay, Asynchronous Transfer Mode (ATM) and Internet Protocol (IP) Packet aver SONET (PoS). The characteristics of voice and data traffic are very different, however; while voice services operate at low speed (8-64 kbps) with substantially constant data rate, data services have a very large bandwidth range (typically 64 kbps to more than 1 Gbps) and are characterized by large differences between peak and average data rates. When a TDM network is used to carry data services, the network operator must set aside sufficient bandwidth to handle the peak data rate contracted for by the user. Most of the time, this bandwidth is underutilized. The containers that are assigned to carry the user packet data are therefore filled up with idle bytes, which consume network bandwidth without carrying any useful information.
While the synchronous SONET and SDH networks have been adapted for carrying packet data, circuit emulation services (CES) are developing for transporting SONET and legacy PDH signals over packet networks, such as Internet Protocol (IP) networks. CES allows the network operator to maintain existing TDM service interfaces in a manner transparent to network users, even when the TDM data traffic travels through a core packet network. For example, the CES operator could continue to offer subscribers DS-1 point-to-point service, while within the core network, the DS-1 signals are carried as packets.
Malis et al. describe a protocol that can be used to carry SONET frames over packet network in an Internet Engineering Task Force (IETF) draft entitled, “SONET/SDH Circuit Emulation over Packet (CEP)” (draft-ietf-pwe3-sonet-00.txt, July, 2002), which is incorporated herein by reference. This document, alone with other IETF drafts cited herein, is available at www.ietf.org. The CEP protocol described by Malis et al. provides a method for emulating the key elements of traditional SONET/SDH SPE services across a packet-switched network, without making any assumptions about the contents of the SPE. It is therefore applicable to emulation of SONET and SDH circuits carrying any type of payload.
According to the CEP protocol, a SONET OC-N signal is terminated at the packet network ingress node, and the SPE is broken into fragments of fixed length. A CEP header is prepended to each fragment. The resulting packet may optionally be encapsulated with a RTP header (as defined by IETF RFC 1889) for transmission over the packet network. At the egress node from the packet network, the CEP packet stream is buffered to absorb delay variations, and the data payload is converted back into a SONET TDM signal using the CEP header information. The CEP header includes, inter alia, a structure pointer, which indicates the beginning of the STS-1 POH within the CEP packet payload (or contains a default value if the packet does not contain the beginning of the POH). The CEP header also contains bits indicating adjustments of the TOH pointer, which are used to advance or delay the SPE at the egress node in order to preserve the SPE timing between the two circuit emulation endpoints. In addition, the CEP header includes a sequence number (used to correct packet misordering) and a D bit that is used to invoke a dynamic bandwidth allocation (DBA) mode. The DBA mode is used optionally to conserve bandwidth on the packet network by avoiding transmission of trivial SPEs during SONET circuit outages and other abnormal conditions.
SONET frames that are encapsulated in accordance with the CEP protocol may be transported over various types of packet networks. Malis et al. specifically describe the use of Multiprotocol Label Switching (MPLS) tunnels for this purpose. MPLS is described in detail by Rosen et al., in IETF Request for Comments (RFC) 3031, entitled “Multiprotocol Label Switching Architecture” (January, 2001), which is incorporated herein by reference. In conventional IP routing, each router along the path of a packet sent through the network analyzes the packet header and independently chooses the next hop for the packet by running a routing algorithm. In MPLS, however, each packet is assigned to a Forwarding Equivalence Class (FEC) when it enters the network, depending on its destination address. The packet receives a short, fixed-length label identifying the FEC to which it belongs. All packets in a given FEC are passed through the network over the same path by label-switching routers (LSRs). Unlike IP routers, LSRs simply use the packet label as an index to a look-up table, which specifies the next hop on the path for each FEC and the label that the LSR should attach to the packet For the next hop.
When IP packets are passed through a MPLS tunnel, the routing label is removed at the egress node, which then simply routes the packet over its next hop using the packet's IP header. There is no need for the label to tell the egress node what to do with the packet, since the existing IP header, which was applied to the packet before it entered the tunnel, provides all of the necessary information. When layer 2 packets, such as Ethernet frames or ATM cells, are sent through a MPLS tunnel, however, the standard layer 2 media access control (MAC) header that brought the packet to the ingress node does not contain all the information that the egress node requires for delivering the packet to its destination. There is thus a need for a label that tells the egress node how to treat the received packet. This need applies, as well, to CES packets, such as those created in accordance with the above-mentioned CEP protocol.
In response to this problem, Martini et al. have proposed to add a “pseudo wire” label (or PW label) to the stack of labels used in transporting layer 2 packets through MPLS tunnels. This proposal is described in detail in an IETF draft entitled “Transport off Layer 2 Frames over MPLS” (draft-ietf-pwe3-control-protocol 01.txt, November 2002), which is incorporated herein by reference. In accordance with the protocol proposed by Martini et al., before initiating the layer 2 service, a MPLS tunnel is established between the ingress and egress nodes. To set up the required PW label binding for the layer 2 service, the ingress node sends a signaling packet to the egress node carrying a PW type, a group ID and a PW ID. The PW type specifies the type of layer 2 service to be carried between the tunnel endpoints, such as Frame Relay, ATM, Ethernet, High-level. Data Link Control (HDLC), Point-to-Point Protocol (PPP) or CEP (referred to by Martini et al. as, “CEM”). The group ID represents an administrative group or PWs, and is used for administrative operations on the group. The PW ID is used by the layer 2 service endpoints to associate the locally-configured service with the tunnel.
The protocol defined by Malis et al. specifies that when CEP packets are to be transported through MPLS tunnels, a MPLS label stack is pushed on top of each CEP packet. The MPLS label stack includes the PW label (referred to by Malis et al. as the “VC label”) as the last label prior to the optional RTP header and the CEP header. The PW label is preceded by one or more MPLS tunnel labels, depending on how the CEP packets are to be transported through the packet network.
A number of methods have been suggested for compressing the contents of SONET frames that are to be transported over packet networks by CES. For example, compression methods for packetized SONET/SDH payloads are described by Cohen in PCT Patent Publication WO 02/095958 A2, whose disclosure; is incorporated herein by reference. These methods use the C2 signal label byte in the SONET POH to choose a compression algorithm to be applied to the SONET SPE payload. For example, the C2 byte may be used to identify unequipped frames, asynchronous channels, and payloads containing virtual tributaries, HDLC frames or PPP frames. Cohen specifies compression methods that can be applied to these different payload types.
Further aspects of CES are described by Pate et al. in an IETF draft entitled, “TDM Service Specification for Pseudo-Wire Emulation Edge to Edge (PWE3)” (draft-ietf-pwe3-sonet-vt-00.txt, August, 2002), which is incorporated herein by reference. This draft provides, inter alia, bandwidth saving modes for packetizing SONET and SDH frames carrying tributaries or asynchronous signals.